Developers Not Writing Tests
The book has now been published and the content of this chapter has likely changed substanstially.Please see page 263 of xUnit Test Patterns for the latest information.
Developers aren't writing automated tests.
Symptoms
We hear that our developers aren't writing tests. Or maybe we have observed Production Bugs (page X) and we have asked "Why are so many bugs getting through" and have been told "Because we aren't writing tests to cover that part of the software."
Impact
If the team isn't writing automated tests for every piece of software "that could possibly break", it is mortgaging its future. The current pace will not be sustainable over the long haul because the system will be in test debt. It will take longer and longer to add new functionality and refactoring of the code to improve the design will be fraught with peril (therefore it will happen less and less frequently.) This is the beginning of a trip down the proverbial "slippery slope" to traditional paranoid, non-agile development. If that is where we aspire to be, we should stay the course. Otherwise, it is time to take action.
Causes
Cause: Not Enough Time
A probable cause is that developers are having trouble writing tests in the time they are given to do the development. This could be caused by too aggressive a development schedule or them being told "don't waste time writing tests" by their supervisors or team leaders. It could also be caused by them not having the skills to write tests efficiently and not being given the time to work their way up the learning curve.
If time is what they need, we'll need to adjust the project schedule to give them the time. This should only need to be a temporary adjustment while they develop the skills and test automation infrastructure that enables them to write the tests more quickly. In our experience, once developers have internalized the process, they can write the tests and the code in the same time as it used to take to write and debug just the code. The time spent writing the tests is more than compensated for by the time not spent in the debugger.
Cause: Hard to Test Code
Another common cause, especially with "legacy software" (defined for our purposes as any software that doesn't have a complete suite of automated tests) is that the design of the software is not conducive to automated testing. This situation is described in more detail in its own smell section, Hard-to-Test Code (page X).
Cause: Wrong Test Automation Strategy
The cause may also be a test environment or test automation strategy that is leading to Fragile Tests (page X) or Obscure Tests (page X) that take too long to write. We need to ask the "five why's" [TPS] to find the root causes. Then we can address those causes and start getting the ship back on course.
Trouble-Shooting Advice
Project level smells such as Developers Not Writing Tests are more likely to be detected by a project manager, Scrum master or team lead than by a developer. As managers, we may not know how to fix the problem but our awareness and recognition of it is what matters. This allows us to ask the development team questions about why they aren't writing tests, in which circumstances and how long it is taking to write tests when they do write tests. Then we can encourage and empower them to come up with ways of addressing the root causes so that they are writing all the necessary tests.
We'll have to give them our full support in carrying out whatever improvement plan they come up with. That support will have to include the time to learn the requisite skills and build or set up the necessary test infrastructure. And we shouldn't expect things to turn around overnight. We might set process improvement goals for each iteration such as "20% reduction in code not tested" or "20% improvement in code coverage." The goals should be reasonable and high-enough level that they encourage the right behavior as opposed to just making the numbers look good. (A goal of 205 more tests written could be achieved without increasing the test coverage one iota simply by splitting tests into smaller pieces or cloning tests.)
Copyright © 2003-2008 Gerard Meszaros all rights reserved